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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings 
which will directly affect or be directly affected by or have a bearing on the Board's decision in 
the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained in 
the brief is correct, 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is * 
substantially correct. The changes are as follows: 

As indicated in the advisory action dated 8/17/2005, as well as the Status of Amendments 
After Final provided by the appellant on 1/26/2006, the amended' claims presented 8/03/2005 
have been entered and the rejection of claims 13-14 under 35 U.S.C. 1 12 2 nd Paragraph was 
withdrawn, as indicated in the advisory action dated 8/17/2005. 

The remaining grounds of rejection indicated by the appellant are correct. 
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(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

No evidence is relied upon by the examiner in the rejection of the claims under appeal. 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claims 1, 4-7, 15, and 18-25 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Peng (US Patent Number 6,317,754), and further in view of Delaney et 
al. (US Patent Number 6,374,289) hereinafter referred to as Delaney. 

Regarding claim 1, Peng disclosed a method for securely sharing resources over a peer- 
to-peer network (See Peng Col. 2 Lines 50-67), comprising: broadcasting a request by a 
requesting peer for a resource over the peer-to- peer network wherein the request contains an 
identification of the resource and the resource identification contains a resource version identifier 
(See Peng Fig. 7 and Cols. 5-6 steps 1 and 3); receiving a response from a responding peer on the 
peer-to-peer network indicating that the responding peer has the requested resource (See Peng 
Col. 5 Step 2); retrieving the requested resource from the responding peer (See Peng Col. 6 Step 
4); and verifying the retrieved resource by ensuring the retrieved resource contains the version 
identifier embedded therein (See Peng Col. 6 Step 6a), however, Peng failed to disclose the 
broadcasted request being broadcasted to a plurality of peers. 

Delaney teaches that in a server based system, downloading all data from one server can * 
overwhelm the server (See Delaney Col. 1 Lines 26-35). Delaney further teaches a system in 
which a broadcast request for data is sent to a plurality of peers and one peer that has the 
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requested data responds to the request (See Delaney Col. 7 Line 10 - Col. 8 Line 20 and Fig. 
2B). 

It would have been obvious to the ordinary person skilled in the art at the time of 
invention to employ the teachings of Delaney in the synchronization system of Peng by 
broadcasting the request for each object to a plurality of peers and receiving the requested object 
from one of the peers. This would have been obvious because the ordinary person skilled in the 
art would have been motivated to protect the servers from being overwhelmed by download 
requests. 

Regarding claim 4, the combination of Peng and Delaney disclosed installing said 
resource (See Peng Col, 6 Step 6b, and Col 15 Step 9). 

Regarding claim 5, the combination of Peng and Delaney disclosed retrieving a catalog 
containing a listing of resources (See Peng Col. 5 Step 2). 

Regarding claim 6, the combination of Peng and Delaney disclosed comparing the listing 
of resources with resources installed at the requesting peer to determine which resources are to 
be requested over the peer-to- peer network (See Peng Cols. 5-6 Step 3). 

Regarding claim 7, the combination of Peng and Delaney disclosed requesting each 
resource to be requested in a separate transaction such that each resource to be requested may be 
retrieved from a same or different responding peer (See Delaney Col. 7 Lines 13-18). 

Regarding claim 15, the combination of Peng and Delaney disclosed a computer program 
product for securely sharing resources over a peer-to- peer network (See Peng Col. 9 Lines 39- 
42), comprising: computer code that broadcasts a single request to a plurality of peers by a 
requesting peer for a resource over the peer-to-peer network wherein the request contains an 
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identification of the resource and the resource identification contains a resource version 
identifier; computer code that receives a response from a responding peer on the peer- to-peer 
network indicating that the responding peer has the requested resource; computer code that 
retrieves the requested resource from the responding peer; computer code that verifies the 
retrieved resource by ensuring the retrieved resource contains the version identifier embedded 
therein; and a computer readable medium that stores said computer codes (See the rejection of 
claim 1 above and further it was inherent that the application was comprised in a computer 
readable medium in order for the code to have been executed and for the system to have 
operated). 

Regarding claim 18, the combination of Peng and Delaney disclosed computer code that 
installs said resource (See the rejection of claim 4 above). 

Regarding claim 19, the combination of Peng and Delaney disclosed computer code that 
retrieves a catalog containing a listing of resources (See the rejection of claim 5 above). 

Regarding claim 20, the combination of Peng and Delaney disclosed computer code that 
compares the listing of resources with resources installed at the requesting peer to determine 
which resources are to be requested over the peer-to-peer network (See the rejection of claim 6 
above). 

Regarding claim 21, the combination of Peng and Delaney disclosed computer code that 
requests each resource to be requested in a separate transaction such that each resource to be 
requested may be retrieved from a same or different responding peer (See the rejection of claim 7 
above). 
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Regarding claim 22, the combination of Peng and Delaney disclosed that the responding 
peer scans a list of local aliased copies to determine if the responding peer has a local version of 
the requested resource (See Delaney Col. 7 Lines 26-39). 

Regarding claim 23-24, the combination of Peng and Delaney disclosed that the 
responding peer waits a predetermined randomly generated period of time before responding that 
the responding resource has the requested resource (See Delaney Col. 7 Lines 26-39). 

Regarding claim 25, the combination of Peng and Delaney disclosed that after receiving 
the response, the requesting peer broadcasts a message to the plurality of peers that the requested 
resource has been found (See Delaney Col. 10 Lines 26-35). 

Claims 2, and 16 are rejected under 35 ILS.C 103(a) as being unpatentable over the 
combination of Peng and Delaney as applied to claims 1, and 15 above, and further in view 
of Shostack et al. (US Patent Number 6,298,445) hereinafter referred to as Shostack, 

Peng and Delaney disclosed verifying the received updates (See the rejection of claim 1 
above), but failed to disclose verifying a digital signature of the update. 

Shostack teaches an updating system should verify the integrity of updates by checking a 
digital signature of the update upon receipt of the update and prior to installing the update (See 
Shostack Fig. 4A Step 1 10, Fig. 7 and Col. 10 Line 58 - Col. 1 1 Line 4). 

It would have been obvious to the ordinary person skilled in the art at the time of 
invention to employ the teachings of Shostack in the updating system of Peng and Delaney by 
verifying a digital signature of each update after receipt and prior to installing the update. This 
would have been obvious because the ordinary person skilled in the art would have been 
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motivated to protect the recipient from update files that had been maliciously tampered with, as 
well as to prevent security vulnerabilities in the recipient. 

Claims 3, and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over the 
combination of Peng, Delaney, and Shostack as applied to claims 2, and 16 above, and 
further in view of Verisign (Verisign gets US approval for 128-bit key certificates export). 

Peng, Delaney, and Shostack disclosed verifying a digital signature of an update file (See 
rejection of claim 2 above), but failed to disclose the digital signature being a 1024-bit Verisign 
digital signature. 

Verisign teaches that a 1024-bit Verisign digital signature provides digital signatures for 
today's strongest cryptographic technologies (See Verisign Page 2 Lines 22-25). 

It would have been obvious to the ordinary person skilled in the art at the time of 
invention to employ the teachings of Verisign in the updating system of Peng, Delaney and 
Shostack by using a 1024-bit Verisign digital signature for verifying the updates. This would 
have been obvious because the ordinary person skilled in the art would have been motivated to 
provide the best security for the updates. 

Claims 8 and 11 are rejected under 35 U.S.C 103(a) as being unpatentable over 
Radatti (US Patent Application Publication 2002/0170052), and further in view of Delaney. 

Regarding claim 8, Radatti disclosed a product updating service for automatic and secure 
updating of a product installed at a node of a network (See Radatti Abstract), comprising: 
automatically downloading a catalog containing a current listing of resources for the product at a 
predetermined time (See Radatti Paragraphs 0013, .0036, and 0038-0044, and 0053 and 0092), 
each resource being identified by a resource version identifier (See Radatti Paragraph 0041); 
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comparing the listing of resources in the catalog with resources installed at the node to determine 
which resources are to be requested over the network (See Radatti Paragraphs 0068 and 0094); 
requesting each resource to be requested in a separate transaction over the network (See Radatti 
Paragraphs 0069 and 0094 and Fig 2), retrieving each resource to be requested in the network 
and the Internet (See Radatti Paragraph 0069 and Fig. 2); and verifying each retrieved resource 
by ensuring the retrieved resource contains the version identifier embedded therein (See Radatti 
Paragraph 0093-0094), however, Radatti failed to disclose broadcasting the request for code over 
a peer-to-peer network and recei ving the code from a member of the peer-to-peer network. 

Delaney teaches that in a server based system, downloading all data from one server can 
overwhelm the server (See Delaney Col. 1 Lines 26-35). Delaney further teaches a system in 
which a broadcast request for data is sent to a plurality of peers and one peer that has the 
requested data responds to the request (See Delaney Col. 7 Line 10 - Col. 8 Line 20 and Fig. 
2B). 

It would have been obvious to the ordinary person skilled in the art at the time of 
invention to employ the teachings of Delaney in the product updating system of Radatti by 
broadcasting the request for code to a plurality of peers and receiving the requested code from 
one of the peers. This would have been obvious because the ordinary person skilled in the art 
would have been motivated to protect the servers from being overwhelmed by download 
requests. 

Regarding claim 1 1, the combination of Radatti and Delaney disclosed installing each of 
the retrieved resources (See Radatti Paragraphs 0069-0070). 
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Claims 9, and 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over the 
combination of Radatti and Delaney as applied to claim 8 above, and further in view of 
Shostack. 

Radatti and Delaney disclosed verifying the received code (See the rejection of claim 8 
above), but failed to disclose verifying a digital signature of the code. 

Shostack teaches an updating system should verify the integrity of updates by checking a 
digital signature of the update upon receipt of the update and prior to installing the update (See 
Shostack Fig. 4A Step 110, Fig. 7 and'Col. 10 Line 58 - Col. 1 1 Line 4). 

It would have been obvious to the ordinary person skilled in the art at the time of 
invention to employ the teachings of Shostack in the updating system of Radatti and Delaney by 
verifying a digital signature of each update after receipt and prior to installing the update. This 
would have been obvious because the ordinary person skilled in the art would have been 
motivated to protect the recipient from update files that had been maliciously tampered with, as 
well as to prevent security vulnerabilities in the recipient. 

Claims 10, and 14 are rejected under 35 U.S.C* 103(a) as being unpatentable over 
the combination of Radatti, Delaney, and Shostack as applied to claims 9, and 13 above, 
and further in view of Verisign. 

Radatti, Delaney, and Shostack disclosed verifying a digital signature of an update code 
(See rejection of claim 9 above), but failed to disclose the digital signature being a 1024-bit 
Verisign digital signature. 

Verisign teaches that a 1024-bit Verisign digital signature provides digital signatures for 
today's strongest cryptographic technologies (See Verisign Page 2 Lines 22-25). 
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It would have been obvious to the ordinary person skilled in the art at the time of 
invention to employ the teachings of Verisign in the updating system of Radatti, Delaney, and 
Shostack by using a 1024-bit Verisign digital signature for verifying the updates. This would 
have been obvious because the ordinary person skilled in the art would have been motivated to 
provide the best security for the updates. 

(10) Response to Argument 
Issue #1 

Because there are no intervening references relied upon in the present application, the 
lack of support under 35 U.S.C. 112 for claims 2-3, 9-10, 13-14, and 16-17 has been withdrawn. 
Issue #2 

The rejection of claims 13-14 under 35 U.S.C. 1 12 2 nd Paragraph was previously 
withdrawn in the advisory action dated 8/1 7/2005. 
Issue #3 

Group #1: Claims 1 and 15 

The appellant argues that Peng and Delaney are non-analogous art and therefore 
combining the references would not have been obvious. It has been held that a prior art 
reference must either be in the field of applicant's endeavor or, if not, then be reasonably 
pertinent to the particular problem with which the applicant was concerned, in order to be relied 
upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 
USPQ2d 1443 (Fed. Cir. 1992). During patent examination, the pending claims must be "given 
their broadest reasonable interpretation consistent with the specification." In re Hyatt, 21 1 F.3d 
1367, 1372, 54 USPQ2d 1664, 1667 (Fed. Cir. 2000). In this case, very specifically, Peng is 
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related to synchronizing servers, and Delaney is related to distributing data packages. However, 
in general, both Peng and Delaney belong to the analogous art of data transfer to a device. Peng 
involves transferring data objects to one device from another (See Peng Col. 6 Step 4). Delaney 
involves transferring data objects to one device from a plurality of devices (See Delaney Col. 7 
Line 10 - Col. 8 Line 20 and Fig. 2B). As such, both references belong to the analogous art of 
transferring data objects to a device. The differences between the references do not render them 
as non-analogous art. The appellants assertion that Peng is not related to the art of distributing 
data packages is incorrect as Peng clearly discloses distributing data packages from one device to 
another in Col. 6 Lines 18-21, "If the identifier of an object appears in the list of identifiers 
received from the first server, it is sent to the first server whole." Furthermore, as pointed out in 
the rejection of claim 1, Delaney recognized that when data is only distributed from one server 
the server can become overloaded and proposed a solution involving peer-to-peer distribution. 
This can be seen in Delaney Col. 1 Lines 16-35 and Col. 7 Paragraph 2. Therefore, the examiner 
respectfully disagrees with the appellants stance. 

The appellant argues that "synchronizing servers does not allow for specific 
requests/broadcasts to be made". This in fact is not the case as Peng clearly provides specific 
requests from a first server to a second server in the form of identifiers representing objects 
which need to be updated in the first server, as can be seen in Peng Cols. 5-6 Step 3 and 
especially step 3c. By sending these identifiers to the second server, the first server is requesting 
the updated objects from the second server. 

The appellant argues that Peng did not disclose "verifying the retrieved resource by 
ensuring the retrieved resource contains the version identifier embedded therein". Peng clearly 
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disclosed comparing the version identifier of the received object to the requested version 
identifier. in col. 6 Section 6a and acting when they were equal. "If the received object or update 
has a version vector or time stamp older than or equal to the version vector of the corresponding 
object in the first server, . . .". The version vector of the corresponding object in the first server 
was the version vector in the request (See Peng Col. 5 Step 1). The claim language does not 
specify what action is taken in response to the verifying that the received resource contains the 
same version identifier as the request, but instead merely recites verifying that the identifier is 
embedded in the retrieved resource. As explained above, Peng does check (verify) that the 
version vector in the request matches the version vector in the received object, and therefore the 
examiner believes that this portion of Peng meets this limitation of the claim and therefore 
respectfully disagrees with the appellant's argument. 

The appellant argues that Peng "compares version vectors two times". The examiner is 
unsure what this argument is meant to show as there is no limitation stating that the version 
vectors cannot be compared multiple times. 

The appellant argues that Peng does not verify that the "received resource has the 
originally requested version identifier embedded therein". In response to appellant's argument 
that the references fail to show certain features of appellant's invention, it is noted that the 
features upon which appellant relies (i.e., "originally requested version identifier") are not 
recited in the rejected claim(s). Although the claims are interpreted in light of the specification, 
limitations from the specification are not read into the claims. See In re Van Geuns, 988 
F.2d 1 181, 26 USPQ2d 1057 (Fed. Cir. 1993). Simply because the claim language recites the 
request containing a version identifier does not limit the scope of the claim such that the claimed 
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version identifier must identify a specific requested version. The claim limitation simply 
requires a version identifier to be included in the request. Peng disclosed such a request in Cols. 
5-6 and therefore meets the limitation of the claim. 

The appellant argues that Peng does not disclose verifying that a specifically requested 
resource is in fact the same resource received. Once again, in response to appellant's argument 
that the references fail to show certain features of appellant's invention, it is noted that the 
features upon which appellant relies (i.e., "verifying that a specifically requested resource is in 
fact the same resource received") are not recited in the rejected claim(s). Although the claims 
are interpreted in light of the specification, limitations from the specification are not read into the 
claims. See In re Van Geuns, 988 F.2d 1 181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claims 
recite ensuring that the received resource contains the same version identifier as the request. 
There is no language limiting the scope to verifying that a specifically requested resource is in 
fact the same resource received. Only a broadly claimed limitation of verifying the received 
resource is provided in the claim and no claim language is directed towards ensuring that the 
received resource is the same as a specifically requested resource. 

Group #2: Claims 6 and 20 

The appellant argues that Peng did not disclose "determining] which resources are to be 
requested over the peer-to-peer network ". The examiner pointed to Step 3 of Peng in Cols. 5-6 
when addressing this limitation because in Step 3 of Peng the first server determines which 
resources will be requested. In the combination of Peng and Delaney, as presented in the 
rejection dated 6/24/2005, the request is broadcast to a peer-to-peer network, as taught by 
Delaney. 
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The appellant argues that the examiner pointed to Radatti when addressing this particular 
argument in the advisory action dated 8/17/2005. However this is not the case. It is clearly seen 
that this particular argument, with regards to Peng not disclosing "determine[ing] which 
resources are to be requested over the peer-to-peer network ", was addressed by the examiner on 
page 2 Lines 40r43, wherein the examiner pointed out the arguments against the references 
individually, when the rejection was based on a combination of references, was not found 
persuasive. 

Group #3 : Claims 7 and 2 1 

The appellant argues that Delaney teaches away from sending 6ut individual requests for 
each resource when stating that "[o]ptionally and preferably, if more than one data package is 
desired, a list of requested data packages is included in the request message rather than a single 
MD5 digest, in order to reduce the total number of request messages on the network" (see Col, 7 
lines 22-25). The examiner points out a key word in this cited portion of Delaney, "Optionally". 
Delaney makes no requirement that a list be sent out, but rather states that it is optional. This is 
not teaching away from a sending out individual responses, but instead it is merely disclosing 

r 

one preferred embodiment. Therefore, in the combination it is obvious that sending a list instead 
of an individual request is optional, and therefore the combination meets the limitations of the 
claim language. 
Issue #4 

Group #1: Claims 2 and 16 

The appellant relies on the arguments with respect to Issue #3, Group #1, which have 
already been addressed above and will not be further addressed below. 
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Issue #5 

Group #1: Claims 3 and 17 

The appellant relies on the arguments with respect to Issue #3, Group #1, which have 
already been addressed above and will not be further addressed below. 
Issue #6 

Group #1 : Claims 8 and 11' 

The appellant argues that Radatti did not disclose "verifying each retrieved resource by 
ensuring the retrieved resource contains the version identifier embedded therein". Appellant 
further argues that Radatti Paragraph [0003] (should read [0093]) merely teaches verification of 
file integrity using hashes. The examiner agrees that [0093] discloses that a hash of a file is 
compared with hash in appropriate server software product information in order to determine the 
integrity of the file. In other words, in order to ensure that a file contains everything it was 
meant to contain (i.e. version number for a module as in paragraphs 0084-0088), the hash of the 
file is compared to a previously generated hash (in the server software product information) and 
if the hashes match it is determined that the file is not corrupt and contains all data it was meant 
to contain (i.e. version number for a module as in paragraphs 0084-0088). In the description of a 
module which was downloaded to the client from the server (See Paragraph 0087) a "hash of the 
module. ..will be used by update manager to verify that the module was not corrupted in 
transmission. The only description of how to use this hash for integrity purposes is in paragraph 
[0093]. As can be seen in the example of paragraph [0087] the version identifier is included in 
the module ("FROM 2.9 TO 3.0"). This version identifier (i.e. 3) is also found in the server 
"update_index" as shown in paragraphs [0083]-[0084] (See paragraphs [0038]-[0046] for a 
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description of the formatting information of a record in the updatejndex). Because the hash of 
the module is verified, and the hash included the version identifier, the version identifier in the 
module was inherently verified. Because the version identifier of the module was included in the 
server update_index (catalog), the limitation of verifying the received' resource by ensuring that 
the version identifier (that was also contained in the catalog) was embedded in the received 
resource (module) was disclosed by Radatti. 
Issue #7 . 

Group #1: Claims 9 and 13 

The appellant relies on the arguments with respect to Issue #6, Group #1, which have 
already been addressed above and will not be further addressed below. 
Issue #8 

Group #1: Claims 10 and 14 

The appellant relies on the arguments with respect to Issue #6, Group #1, which have 
already been addressed above and will not be further addressed below. 

To summarize, the examiner has addressed the appellant's arguments: 

As per Issue #1, the examiner has withdrawn the lack of support in the provisional 
applications. 

As per Issue #2, the amendment which the appellant argues has not been entered was in 
fact entered on 8/17/2005. 

As per Issue #3, the examiner has addressed the appellant's argument that Peng and 
. Delaney are non-analogous art and has shown that in fact the opposite is true. The examiner 
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showed that although Peng does involve synchronizing servers, Peng also disclosed sending 
requests for objects. The examiner showed that Peng did disclose verifying that the received 
resource contained the version identifier that was in the request. The examiner further 
commented on the appellant's remark regarding the comparison of the version identifier two 
times. The examiner also pointed out that neither an "originally requested version identifier", 
nor verifying that the received resource was the specifically requested resource, are not recited in 
the claim language. The examiner further showed that the combination of Peng and Delaney did 
show determining which resources would be requested over a peer-to-peer network, and the 
examiner addressed the allegation that Delaney teaches away from separate transactions. 

As per Issue #4, the examiner has addressed the appellant's arguments with respect to 
Issue #3. 

As per Issue #5, the examiner has addressed the appellant's arguments with respect to 
Issue #3. 

As per Issue #6, the examiner has addressed the appellant's argument that Radatti did not 
verify that the version identifier was embedded in the received resource and showed that because 
Radatti verified the hash of the received module and the hash was taken over the entire module 
including the version number which was embedded by the server, Radatti did in fact verify that 
the version identifier was embedded in the received module. 

As per Issue #7, the examiner has addressed the appellant's arguments with respect to 
Issue #6. 

As per Issue #8, the examiner has addressed the appellant's arguments with respect to 
Issue #6. 
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For the above reasons, it is believed that the rejections should be sustained. 

Respectfully submitted, 




Matthew Henning 



March 22, 2006 
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